There are many different types of systems in which signals or data are passed in a directed flow from source components (where the signals or data originate or enter the system), through transfer components (which may modify the signals or data), to sink components (where the signals or data terminate or exit the system). A multimedia computer is an example of such a system. In a multimedia computer, audio and video data might originate from a mass storage system, pass through decompression components (implemented in hardware or software), and be supplied to a speaker and a display device.
The invention described below will be used in a computer system for retrieving media streams of different types and for processing and rendering such media streams on appropriate output devices. A media stream is represented by a sequence of samples or digital sample values. For instance, an audio media stream is represented by a series of digital values, each indicating the instantaneous intensity of the desired audio signal at a particular point in time.
The computer system is configured to include a plurality of processing components implemented in software, including source, transfer, and sink processing components. Each processing component might be associated with one or more hardware devices and associated device driver programs. The invention can also be used in other contexts, such as in systems that implement the various components in hardware or firmware.
FIG. 1 shows an example of an interconnected system of processing components in accordance with the prior art. Functionally, the system retrieves a compressed stream of sampled data representing a video segment from a mass storage device 12, decompresses the data, and displays it on a display device 13. In addition to the two physical devices (mass storage device 12 and display device 13), the system includes a source processing component 14, a transfer or intermediate processing component 15, and a sink processing component I6. Source processing component 14 is associated with a device driver 17, in this case a hard disk driver, that handles details of communications with mass storage device 12. Source processing component 14 retrieves data from hard disk 12 at appropriate intervals and prepares or formats the data for subsequent handling by transfer component 15. Transfer component 15 is associated with decompression software 18 for decompressing data into a format suitable for handling by video display hardware. The decompressed data is received by sink component 16, which is associated with a video display driver 19 for transferring the decompressed data to a video display card and associated display device 13.
In many multimedia applications, there are multiple media streams that must be presented together. Inter-stream synchronization is required if particular media samples from different media streams must be rendered simultaneously. One example of this is where separate audio and video streams are to be rendered together. In this case, the audio must be fairly closely synchronized to the video. Another example is that of multiple graphic sprites; it is often desired for such independent sprites to maintain a time-based relationship between each other so that they appear to interact.
Intra-stream synchronization is required if one media stream must be initiated immediately after a previous media stream. This type of synchronization is performed relative to media streams rather than to the individual samples of media streams. Intra-stream synchronization is needed when the transition from one media stream to another must appear or sound seamless to a viewer or listener.
In a multi-component system such as described above with reference to FIG. 1, each media stream will typically be processed by its own set of processing components. This can make synchronization difficult. Theoretically, inter-stream synchronization can be achieved by beginning the rendering of each stream at the same time and rendering subsequent samples at appropriate and constant rates. However, timing within the various sets of processing components is typically not accurate enough for this type of synchronization to work well, resulting in an amount of drift or skew that is often noticeable. One prior art way to correct for such drift is to re-synchronize the media streams every so often. However, this method is somewhat disconcerting for a viewer, who sees or hears a noticeable "jump" in the media presentation whenever the re-synchronization occurs.
Another synchronization challenge results from the fact that the various processing components each have their own propagation delays. To make things worse, these propagation delays are sometimes variable with time. Because of such propagation delays, simultaneously beginning the rendering process for two different media streams does not necessarily mean that the actual rendering will begin simultaneously. One way to handle this is to calculate or estimate the propagation delays in advance, and to begin the rendering process for two different media streams at different times to account for the difference in propagation delays. This technique depends, however, on the accuracy with which the propagation delays can be predicted. It is not always possible to accurately predict such propagation delays.